The standard definition of Electronic Data Interchange, or EDI, is "the automated computer-to-computer exchange of structured business documents, between an enterprise and its vendors, customers, or other trading partners." The form of these documents is based on the use of industry, national, and international standards.
Traditionally, an application (or person) generates a paper document, on a multi-part form. This is routed for approval signatures. Copies are forwarded to various internal departments for filing, while one or more copies are sent through the postal service and/or FAX to a trading partner (customer, vendor or other).
When the document reaches the trading partner, it's routed to and re-entered into another system. Here, errors often creep into the data. Paper documents are generated, and the data transfer process begins in reverse. Often this cycle can take as many as ten working days.
Clearly, this antiquated method cannot possibly keep pace with the information transfer requirements of current trading mechanisms. Here is where EDI comes in to play. EDI automates the transfer processes between computers-no matter the make, model, creed or color of those machines, and regardless of their physical location.
Of course, these systems must have "rules." The data cannot be just any data. Formats must agree. Data is structured; assembled in a way that makes it recognizable to both the sending and receiving computers. Business documents usually transferred electronically are grouped into "transaction sets". These include invoices, payment orders, price lists, RFQs, purchase orders, acknowledgements, shipping notices, and change requests, to name just a few.
The existence of heterogeneous computing environments necessitates standards for data interchange. EDI standards are meant to solve three basic issues:
The structure for the message envelope that surrounds the data to be transmitted; PA1 The structure for the message content-the actual data, and; PA1 The vehicle to handle the links to external computers through communications protocol conversion.
The Message Envelope PA0 The Message Content PA0 External Computer Links PA0 The Problem
Like regular mail, EDI requires that the data transmitted over a network from one trading partner to another be sent in an envelope. Regardless of the EDI standards to which a company subscribes, most message envelopes must begin with a header segment message and end with a trailer segment message. Essentially, these take the place of the "Mail To" address in electronic mail message envelopes also contain a code to identify at the highest level what type of data is contained.
Message envelopes are defined by most if not all EDI standards, including ANSI X12, EDIFACT, TDCC, and others. Message standards are also used with electronic mail in standards such as the CCITT X.400 series of internationally recognized messaging recommendations.
In addition to the message envelope, EDI transmissions have content data. This data usually consists of a stream of data segments and data elements which can include purchase-order numbers, terms and conditions, and bill-to and ship-to fields. Also, the content of the message envelope is structured on EDI standards to which all trading partners agree.
Communications standards are required to transport the EDI envelopes from one trading partner to another. These communications protocols are standardized to be able to support not only EDI documents and data, but most forms of electronic information distribution. The protocols include X.25, the international standard for packet switching networks; 2780/3780, a data communications associated with batch processing, also known as bisynchronous communication; and others.
To facilitate EDI structured-data transactions, both the customer and vendor must have computer systems enabled with facilities to send and receive electronic data. Furthermore, these facilities must be able to determine the format and content of these electronic "messages" pursuant to EDI standards as previously discussed. The solution to date has been for vendors and vendees (trading partners) to first reach an agreement on the version of EDI standards they will adhere to, and then determine a format for which data should appear to each party for each class of transaction and type of electronic document, such as a purchase order, and order acknowledgement, a change order, and the like.
Prior art relies on the existence of a pre-defined "template" which describes the format and nature of the incoming data in terms of records and fields. Such things as the EDI standard format version must be set out. The order and limitations with which records, segments, and elements are packaged must be defined within the template. However, if incoming data fails to conform to the template, the transaction fails and an error condition results. Accordingly, the prior art lacks in two respects. First, should a transaction data stream fail to either transmit data in the order expected, or transmit the structure according to a template established for the sender, the entire transaction is aborted, requiring a new transmittal.
Secondly, in order to allow electronic transmission of transactions, a template must first be created. This additional overhead slows the transaction at large, and can in some cases as a practical matter, cancel a "deal" between vendor and yendee where the transaction is extremely price-sensitive. For example, suppose the vendor would like to effect a major transaction involving commodity priced material. If in order to consummate the transaction (i.e., accept the order into vendor's sales transaction system), the yendee and vendor must create a "template" to accept order data from the yendee, the transaction is slowed and may ultimately cost one or the other party due to a market price change in the interim. Therefore, prior art is unable to compensate for price or time-sensitive transactions because an electronic data interchange format template is required before a transaction between a customer and vendor can be effected.
However, prior art does attempt to at least facilitate EDI transactions. U.S. Pat. No. 4,951,196 (Jackson) provides a mechanism for constructing templates to receive incoming EDI data and present the data on a computer display, printer, or in a file on disk. Jackson enables trading partners to define formats of a dictionary-structured business transaction which provide the basis for subsequent entry and translation of EDI structured-data transactions. This, however, falls short of solving the problem because Jackson only enables creation of templates for mapping data on to a display as received from the originator. In the absence of a template definition, the Jackson system is of little or no utility in facilitating time-sensitive business data transactions.
Accordingly, there remains a need for a system which can enable the receipt, manipulation, and re-transmission of EDI structured-data in the absence of any pre-defined template or display format. Likewise there remains a need for a method of accepting EDI structured-data without prior knowledge of the chosen EDI Standard version for the incoming data streams.